The speed slider updates only the algorithms currently registered in MainController.algorithms. In this app, Settings creates its own algorithmList of new SortingAlgorithm instances and later swaps them into MainController via setAlgorithm(...) / setAlgorithms(...), so newly selected algorithms may not inherit the user’s chosen speed settings. Consider storing the selected delay settings centrally (e.g., in MainController) and applying them inside setAlgorithm/setAlgorithms, or applying the slider values directly to Settings.algorithmList as well.

proc is a RenderContext, but this code casts it back to PApplet to call circle(). That will throw ClassCastException when a non-Processing RenderContext (e.g., HeadlessRenderContext) is used, undermining the headless rendering goal. Consider extending RenderContext with the drawing operations the visualizations need (e.g., circle) and implementing them in both MainController and HeadlessRenderContext, or splitting 2D/3D visuals behind separate context interfaces.

Progress percentage uses (half - 1.) as the divisor. When length is 2 (so half == 1), this becomes a division by zero and results in an infinite percentage (casts to Integer.MAX_VALUE), producing bogus UI output. Consider guarding small lengths (e.g., treat 0%/100% specially, or use Math.max(1, half - 1) as the denominator).

The class-level Javadoc claims this is a Fisher–Yates shuffle, but the implementation picks j uniformly from [0, length) for every i, which is not Fisher–Yates and does not produce a uniform permutation. Either update the implementation to a real Fisher–Yates (choose j from [i, length)) or adjust the documentation to match the actual behavior.

Progress percentage divides by (length - 1). For length <= 1, this produces Infinity/NaN and can display nonsensical values (casts to Integer.MAX_VALUE). Consider guarding small lengths (e.g., treat length==1 as 100% and skip the division).

Progress percentage divides by (length - 1). For length <= 1, this yields Infinity/NaN and can display nonsensical values (or potentially propagate to other calculations). Consider guarding length <= 1 and reporting 100% immediately (or use Math.max(1, length - 1) as the denominator).

Progress percentage divides by (swaps - 1). When length is 10–19, swaps becomes 1 and this divides by zero, producing an infinite percentage in the UI string. Handle the swaps <= 1 case explicitly (e.g., report 100% after the single swap, or clamp the denominator with Math.max(1, swaps - 1)).

assertTrue(true) doesn't validate anything and can be removed. If the intent is to verify HeadlessSound is a no-op, use assertDoesNotThrow(() -> sound.playSound(5)) (and optionally cover mute(...) similarly).

The main build now produces a thin target/sorting-visualizer.jar plus copied dependencies, but the JAR manifest doesn’t include a Class-Path, so java -jar target/sorting-visualizer.jar will not find runtime deps unless users use the provided -cp ... dependency/* launch pattern. If you want the jar to remain runnable via java -jar, consider adding a Class-Path manifest entry (pointing at dependency/*) or using a shading/assembly approach for the default build.

In the release profile, appendAssemblyId is true, so the fat jar will be named sorting-visualizer-jar-with-dependencies.jar (while target/sorting-visualizer.jar remains the thin jar). If release automation / download links expect the runnable artifact to be sorting-visualizer.jar, consider setting appendAssemblyId=false or otherwise aligning the produced filename with the expected release asset name.